Doxygen Notes

Unpack the archive, unless you already have done that:

gunzip doxygen-$VERSION.src.tar.gz    # uncompress the archive
tar xf doxygen-$VERSION.src.tar       # unpack it

Run the configure script:

sh ./configure

configure --platform platform-type

configure --with-doxywizard

configure --help

Compile the program by running make:

make

Optional: Generate the user manual.

make docs

Optional: Generate a PDF version of the manual (you will need pdflatex, makeindex, and egrep for this).

make pdf

install

Step 1: Creating a configuration file

Step 2: Running doxygen

Step 3: Documenting the sources

Comment blocks for C-like languages (C/C++/C#/Objective-C/PHP/Java)

• There are several ways to mark a comment block as a detailed description:
  
  • 1.You can use the JavaDoc style, which consist of a C-style comment block starting with two *'s, like this:
    

    /**
     * ... text ...
     */
    

  • 2.or you can use the Qt style and add an exclamation mark (!) after the opening of a C-style comment block, as shown in this example:
    

    /*!
     * ... text ...
     */
    

    In both cases the intermediate *'s are optional, so

    /*!
     ... text ...
    */
    

    is also valid.

  • 3.A third alternative is to use a block of at least two C++ comment lines, where each line starts with an additional slash or an exclamation mark. Here are examples of the two cases:
    

    ///
    /// ... text ...
    ///
    

    or

    //!
    //!... text ...
    //!
    

    Note that a blank line ends a documentation block in this case.

  • 4. Some people like to make their comment blocks more visible
    

    in the documentation. For this purpose you can use the following:

    /********************************************//**
     *  ... text
     ***********************************************/
    (note the 2 slashes to end the normal comment block and start a special comment block).
    

    or

    /////////////////////////////////////////////////
    /// ... text ...
    /////////////////////////////////////////////////
    

• For the brief description there are also several possibilities:
  
  • 1.One could use the \brief
    

    command with one of the above comment blocks. This command ends at the end of a paragraph, so the detailed description follows after an empty line.

    Here is an example:

    /*! \brief Brief description.
     *         Brief description continued.
     *
     *  Detailed description starts here.
     */
    

  • 2.If JAVADOC_AUTOBRIEF is set to YES
    

    in the configuration file, then using JavaDoc style comment blocks will automatically start a brief description which ends at the first dot followed by a space or new line. Here is an example:

    /** Brief description which ends at this dot. Details follow
     *  here.
     */
    

    The option has the same effect for multi-line special C++ comments:

    /// Brief description which ends at this dot. Details follow
    /// here.
    

  • 3.A third option is to use a special C++ style comment
    

    which does not span more than one line. Here are two examples:

    /// Brief description.
    /** Detailed description. */
    

    or

    //! Brief description.
    
    //! Detailed description 
    //! starts here.
    

    Note the blank line in the last example, which is required to separate the brief description from the block containing the detailed description. The JAVADOC_AUTOBRIEF should also be set to NO for this case.

    As you can see doxygen is quite flexible. If you have multiple detailed descriptions, like in the following example:

    //! Brief description, which is
    //! really a detailed description since it spans multiple lines.
    /*! Another detailed description!
     */
    

• Putting documentation after members
  

  If you want to document the members of a file, struct, union, class, or enum, it is sometimes desired to place the documentation block after the member instead of before. For this purpose you have to put an additional < marker in the comment block. Note that this also works for the parameters of a function.

  Here are some examples:

  int var; /*!< Detailed description after the member */
  

  This block can be used to put a Qt style detailed documentation block after a member. Other ways to do the same are:

  int var; /**< Detailed description after the member */
  

  or

  int var; //!< Detailed description after the member
           //!<
  

  or

  int var; ///< Detailed description after the member
           ///<
  

  Most often one only wants to put a brief description after a member. This is done as follows:

  int var; //!< Brief description after the member
  

  or

  int var; ///< Brief description after the member
  

  For functions one can use the @param command to document the parameters and then use [in], [out], [in,out] to document the direction. For inline documentation this is also possible by starting with the direction attribute, e.g.

  void foo(int v /**< [in] docs for input parameter v. */);
  

• Examples
  
  • Here is an example of a documented piece of C++ code using the Qt style:
    

    //!  A test class. 
    /*!  
    A more elaborate class description.
    */
    class Test
    {  
     public:
      //! An enum.
      /*! More detailed enum description. */
      enum TEnum {
        TVal1, /*!< Enum value TVal1. */
        TVal2, /*!< Enum value TVal2. */
        TVal3  /*!< Enum value TVal3. */
      }
      //! Enum pointer.
      /*! Details. */
      *enumPtr,
        //! Enum variable.
        /*! Details. */
        enumVar;
    
      //! A constructor.
      /*!      A more elaborate description of the constructor.    */
      Test();
      //! A destructor.
      /*!
        A more elaborate description of the destructor.
      */
      ~Test();
    
      //! A normal member taking two arguments and returning an integer value.
      /*!
        \param a an integer argument.
        \param s a constant character pointer.
        \return The test results
        \sa Test(), ~Test(), testMeToo() and publicVar()
      */
      int testMe(int a,const char *s);
      //! A pure virtual member.
      /*!
        \sa testMe()
        \param c1 the first argument.
        \param c2 the second argument.
      */
      virtual void testMeToo(char c1,char c2) = 0;
      //! A public variable.
      /*!
        Details.
      */
      int publicVar;
      //! A function variable.
      /*!
        Details.
      */
      int (*handler)(int a,int b);
    };
    

  • using JAVADOC style
    

    This is not according the JavaDoc specification however, where the first sentence of the documentation block is automatically treated as a brief description. To enable this behavior you should set JAVADOC_AUTOBRIEF to YES in the configuration file. If you enable this option and want to put a dot in the middle of a sentence without ending it, you should put a backslash and a space after it. Here is an example:

    /** Brief description (e.g.\ using only a few words). Details follow. */
    

    /**
     *  A test class. A more elaborate class description.
     */
    class Test
    {
     public:
      /**
       * An enum.
       * More detailed enum description.
       */
      enum TEnum {
        TVal1, /**< enum value TVal1. */
        TVal2, /**< enum value TVal2. */
        TVal3  /**< enum value TVal3. */
      }
      *enumPtr, /**< enum pointer. Details. */
        enumVar;  /**< enum variable. Details. */
    
      /**
       * A constructor.
       * A more elaborate description of the constructor.
       */
      Test();
      /**
       * A destructor.
       * A more elaborate description of the destructor.
       */
      ~Test();
    
      /**
       *a normal member taking two arguments and returning an integer value.
       * @param a an integer argument.
       * @param s a constant character pointer.
       * @see Test()
       * @see ~Test()
       * @see testMeToo()
       * @see publicVar()
       * @return The test results
       */
      int testMe(int a,const char *s);
      /**
       * A pure virtual member.
       * @see testMe()
       * @param c1 the first argument.
       * @param c2 the second argument.
       */
      virtual void testMeToo(char c1,char c2) = 0;
      /**
       * a public variable.
       * Details.
       */
      int publicVar;
      /**
       * a function variable.
       * Details.
       */
      int (*handler)(int a,int b);};
    

Documentation at other places

• some structural commands are:
  

  •\struct to document a C-struct. 
  •\union to document a union. 
  •\enum to document an enumeration type. 
  •\fn to document a function. 
  •\var to document a variable or typedef or enum value. 
  •\def to document a #define. 
  •\typedef to document a type definition. 
  •\file to document a file. 
  •\namespace to document a namespace. 
  •\package to document a Java package. 
  •\interface to document an IDL interface.
  

• Here is an example of a C header named structcmd.h that is documented using structural commands:
  

  /*! \file structcmd.h
      \brief A Documented file.
  
      Details.
  */
  /*! \def MAX(a,b)
      \brief A macro that returns the maximum of \a a and \a b.
  
      Details.
  */
  /*! \var typedef unsigned int UINT32
      \brief A type definition for a .
  
      Details.
  */
  /*! \var int errno
      \brief Contains the last error code.
      \warning Not thread safe!
  */
  /*! \fn int open(const char *pathname,int flags)
      \brief Opens a file descriptor.
      \param pathname The name of the descriptor.
      \param flags Opening flags.
  */
  /*! \fn int close(int fd)
      \brief Closes the file descriptor \a fd.
      \param fd The descriptor to close.
  */
  /*! \fn size_t write(int fd,const char *buf, size_t count)
      \brief Writes \a count bytes from \a buf to the filedescriptor \a fd.
      \param fd The descriptor to write to.
      \param buf The data buffer to write.
      \param count The number of bytes to write.
  */
  /*! \fn int read(int fd,char *buf,size_t count)
      \brief Read bytes from a file descriptor.
      \param fd The descriptor to read from.
      \param buf The buffer to read into.
      \param count The number of bytes to read.
  */
  #define MAX(a,b) (((a)>(b))?(a):(b))
  typedef unsigned int UINT32;
  int errno;
  int open(const char *,int);
  int close(int);
  size_t write(int,const char *, size_t);
  int read(int,char *,size_t);
  

Comment blocks in Python

• For Python there is a standard way of documenting the code using so called documentation strings.
  

  Note that in this case none of doxygen's special commands are supported.

  """@package docstring
       Documentation for this module.
  
       More details.
       """
  
       def func():
           """Documentation for a function.
  
          More details.
          """
          pass
  
      class PyClass:
          """Documentation for a class.
  
          More details.
          """
  
          def __init__(self):
              """The constructor."""
              self._memVar = 0;
  
          def PyMethod(self):
              """Documentation for a method."""
             pass
  

• using doxygen style comments
  

  There is also another way to document Python code using comments that start with "##". These type of comment blocks are more in line with the way documentation blocks work for the other languages supported by doxygen and this also allows the use of special commands.

   ## @package pyexample
   #  Documentation for this module.
   #
   #  More details.
  
   ## Documentation for a function.
   #
   #  More details.
   def func():
      pass
  
  ## Documentation for a class.
  #
  #  More details.
  class PyClass:
  
      ## The constructor.
      def __init__(self):
          self._memVar = 0;
  
      ## Documentation for a method.
      #  @param self The object pointer.
      def PyMethod(self):
          pass
  
      ## A class variable.
      classVar = 0;
  
      ## @var _memVar
      #  a member variable
  

Anatomy of a comment block